Telegram Group & Telegram Channel
سوال جالبی از من پرسیده شد جهت افزایش دانش شما عزیزان به اشتراک گذاشتیم ❤️

🤔 سوال توسط amirmohammad Fathollahi پرسیده شد:
من برای api gateway دنبال best practice هستم با ocelot
هرچی ویدیو میبینم صرفا در حد اینه route کنه
ولی راجع به معماری و هندل کردن چندین پروژه حرفی نزدن
اگه کسی منبع خوب یا سمپل کد میشناسه معرفی کنه ممنون میشم
توی معماریش چه کار هایی میکنن چه چیز هایی رو بهش میسپرن
آیا صرفا فقط برای reverse ازش استفاده میکنن یا rate limiting و authentication هم بهش میسپرن
بیشتر سوالم راجع به معماریش هست


💡 جواب:
در واقع API Gateway رو یا باید خودمون پیاده سازی کنیم یا از ابزارهایی مثل Kong استفاده کنیم.
اگر خودمون پیاده سازی کنیم طبیعتاً دسترسی کامل به همه چیز داریم ولی Kong مثلا بهمون یک Dashboardهم میده و شاید در یک سری جاها به اندازه یک API Gateway اختصاصی دست آدم باز نباشه.

حالا وقتی میخواهی خودت پیاده کنی Per Environment باید Config های Routing خودت‌رو داشته باشی یعنی روی Develop با Production باید Configهاشون فرق داشته باشه چونکه آدرس ها در Develop Local و Production قطعا متفاوت هست.
یکی از Best Practiceهایی که معمولا در API Gateway ها در نظر می‌گیرند Code Less می‌کنندش یعنی هیچ کدی داخلش نمی‌گذارند و واقعاً شبیه Gateway عمل میکنه، بدون هیچ Business Logic خاصی.

درباره Rate limit باید بهتون بگم که Trade-off زیاد دارد!
یک موضوع infrastructure ای هست یعنی در لایه Application پیاده نمیشه چون Bottleneck برنامه میشه و اگر مشکل داشته باشه میتونه برنامه بندازه یا کند کنه همچنین میتونه single point of failure باشه.
پیچیدگی Rate Limit زمانی هست که چندین Instance از برنامه ما بالا باشه به همین دلیل Application Layer جای خوبی نیست براش اما اگر برنامه شما اینقدر کوچک هست که یک Instance فقط از API Gateway دارد، بنظرم دوباره فکر کنید آیا واقعاً به microservice نیاز داشتید یا نه!
حالا فرض میکنیم که شما به API Gateway نیاز داشتید و Rate Limit هم قرار هست پیاده کنید بنظر من بهتره در لایه Application خودتون پیاده سازی بشه و اگر واقعاً یک چیز نیاز دارید که خیلی Global باشه و زیرساخت ندارید مثل تیم DevOps بنظرم API Gateway جای خوبی هست

اما در کیس Authentication خیلی Trade-off نداریم!
کنترل رو می‌سپارن به خود Application ها، همان‌طور که گفتم خیلی سعی میشه API Gatewayها Code Less باشن فرض کنیم سرویس A با مدل AModel احراز هویت میشه و سرویس B با مدل BModel و این میتونه در API Gateway پیچیدگی ایجاد کنه و از نظر Separation of Concerns باید API Gateway یک Gateway بمونه واقعاً
به این دلیل که Authentication میتونه خیلی پیچیدگی ایجاد کنه من حداقل ندیدم جایی احراز هویت رو روی Gateway پیاده کنند، ولی این کار نشدنی نیست.
در بعضی از مدل های احراز هویت نیاز هست که Token برای سرویس اصلی که Authentication رو پیاده سازی کرده ارسال بشه و اگر ما در API Gateway احراز هویت رو پیاده سازی کرده باشیم این میتونه باعث بشه API Gateway خودش گلوگاه باشه که درخواست‌ها رو کند کنه و وقتی کندی در سیستم میبینیم نمی‌دانیم سرویس واقعاً مشکل دارد یا API Gateway

اگر نظری دارین در کامنت ها برام بنویسید 👇
Channel: @hasanxdev
Please open Telegram to view this post
VIEW IN TELEGRAM



tg-me.com/hasanxdev/136
Create:
Last Update:

سوال جالبی از من پرسیده شد جهت افزایش دانش شما عزیزان به اشتراک گذاشتیم ❤️

🤔 سوال توسط amirmohammad Fathollahi پرسیده شد:
من برای api gateway دنبال best practice هستم با ocelot
هرچی ویدیو میبینم صرفا در حد اینه route کنه
ولی راجع به معماری و هندل کردن چندین پروژه حرفی نزدن
اگه کسی منبع خوب یا سمپل کد میشناسه معرفی کنه ممنون میشم
توی معماریش چه کار هایی میکنن چه چیز هایی رو بهش میسپرن
آیا صرفا فقط برای reverse ازش استفاده میکنن یا rate limiting و authentication هم بهش میسپرن
بیشتر سوالم راجع به معماریش هست


💡 جواب:
در واقع API Gateway رو یا باید خودمون پیاده سازی کنیم یا از ابزارهایی مثل Kong استفاده کنیم.
اگر خودمون پیاده سازی کنیم طبیعتاً دسترسی کامل به همه چیز داریم ولی Kong مثلا بهمون یک Dashboardهم میده و شاید در یک سری جاها به اندازه یک API Gateway اختصاصی دست آدم باز نباشه.

حالا وقتی میخواهی خودت پیاده کنی Per Environment باید Config های Routing خودت‌رو داشته باشی یعنی روی Develop با Production باید Configهاشون فرق داشته باشه چونکه آدرس ها در Develop Local و Production قطعا متفاوت هست.
یکی از Best Practiceهایی که معمولا در API Gateway ها در نظر می‌گیرند Code Less می‌کنندش یعنی هیچ کدی داخلش نمی‌گذارند و واقعاً شبیه Gateway عمل میکنه، بدون هیچ Business Logic خاصی.

درباره Rate limit باید بهتون بگم که Trade-off زیاد دارد!
یک موضوع infrastructure ای هست یعنی در لایه Application پیاده نمیشه چون Bottleneck برنامه میشه و اگر مشکل داشته باشه میتونه برنامه بندازه یا کند کنه همچنین میتونه single point of failure باشه.
پیچیدگی Rate Limit زمانی هست که چندین Instance از برنامه ما بالا باشه به همین دلیل Application Layer جای خوبی نیست براش اما اگر برنامه شما اینقدر کوچک هست که یک Instance فقط از API Gateway دارد، بنظرم دوباره فکر کنید آیا واقعاً به microservice نیاز داشتید یا نه!
حالا فرض میکنیم که شما به API Gateway نیاز داشتید و Rate Limit هم قرار هست پیاده کنید بنظر من بهتره در لایه Application خودتون پیاده سازی بشه و اگر واقعاً یک چیز نیاز دارید که خیلی Global باشه و زیرساخت ندارید مثل تیم DevOps بنظرم API Gateway جای خوبی هست

اما در کیس Authentication خیلی Trade-off نداریم!
کنترل رو می‌سپارن به خود Application ها، همان‌طور که گفتم خیلی سعی میشه API Gatewayها Code Less باشن فرض کنیم سرویس A با مدل AModel احراز هویت میشه و سرویس B با مدل BModel و این میتونه در API Gateway پیچیدگی ایجاد کنه و از نظر Separation of Concerns باید API Gateway یک Gateway بمونه واقعاً
به این دلیل که Authentication میتونه خیلی پیچیدگی ایجاد کنه من حداقل ندیدم جایی احراز هویت رو روی Gateway پیاده کنند، ولی این کار نشدنی نیست.
در بعضی از مدل های احراز هویت نیاز هست که Token برای سرویس اصلی که Authentication رو پیاده سازی کرده ارسال بشه و اگر ما در API Gateway احراز هویت رو پیاده سازی کرده باشیم این میتونه باعث بشه API Gateway خودش گلوگاه باشه که درخواست‌ها رو کند کنه و وقتی کندی در سیستم میبینیم نمی‌دانیم سرویس واقعاً مشکل دارد یا API Gateway

اگر نظری دارین در کامنت ها برام بنویسید 👇
Channel: @hasanxdev

BY Code With HSN


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/hasanxdev/136

View MORE
Open in Telegram


Code With HSN Telegram | DID YOU KNOW?

Date: |

The STAR Market, as is implied by the name, is heavily geared toward smaller innovative tech companies, in particular those engaged in strategically important fields, such as biopharmaceuticals, 5G technology, semiconductors, and new energy. The STAR Market currently has 340 listed securities. The STAR Market is seen as important for China’s high-tech and emerging industries, providing a space for smaller companies to raise capital in China. This is especially significant for technology companies that may be viewed with suspicion on overseas stock exchanges.

Telegram announces Anonymous Admins

The cloud-based messaging platform is also adding Anonymous Group Admins feature. As per Telegram, this feature is being introduced for safer protests. As per the Telegram blog post, users can “Toggle Remain Anonymous in Admin rights to enable Batman mode. The anonymized admin will be hidden in the list of group members, and their messages in the chat will be signed with the group name, similar to channel posts.”

Code With HSN from sg


Telegram Code With HSN
FROM USA